home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 1 / QRZ Ham Radio Callsign Database - December 1993.iso / arrl / ax_25_1 < prev    next >
Text File  |  1993-11-21  |  31KB  |  801 lines

  1. AX25.DOC
  2.  
  3.          AX.25 Amateur Packet-Radio Link-Layer Protocol
  4.                     Version 2.0  October 1984
  5.  
  6. Copyright (c) 1984 by
  7.  
  8. The American Radio Relay Legue, Inc.
  9.  
  10. Blanket permission to copy this publication by end users for 
  11. noncommercial purposes is hereby granted.  No part of this
  12. work may be reproduced in any form where such copy is offered
  13. in exchange for any payment unless written permission has first
  14. been secured from the publisher.
  15.  
  16. 2.  AX.25 Link-Layer Protocol Specification
  17.  
  18. 2.1  Scope and Field of Operation
  19.  
  20.         In  order  to  provide  a  mechanism  for  the   reliable 
  21. transport  of  data  between  two  signaling  terminals,  it   is 
  22. necessary  to define a protocol that can accept and deliver  data 
  23. over a variety of types of communications links.  The AX.25 Link-
  24. Layer  Protocol is designed to provide this service,  independent 
  25. of any other level that may or may not exist.
  26.  
  27.         This protocol conforms to ISO Recommendations 3309,  4335 
  28. (including DAD 1&2) and 6256 high-level data link control  (HDLC) 
  29. and  uses  some terminology found in these  documents.   It  also 
  30. conforms with ANSI X3.66, which describes ADCCP, balanced mode.
  31.  
  32.         This  protocol  follows,  in principle,  the  CCITT  X.25 
  33. Recommendation,  with the exception of an extended address  field 
  34. and  the addition of the Unnumbered Information (UI)  frame.   It 
  35. also follows the principles of CCITT Recommendation Q.921  (LAPD) 
  36. in the use of multiple links, distinguished by the address field, 
  37. on a single shared channel.
  38.  
  39.         As  defined,  this  protocol will work  equally  well  in 
  40. either half- or full-duplex Amateur Radio environments.
  41.  
  42.         This protocol has been designed to work equally well  for 
  43. direct  connections between two individual  amateur  packet-radio 
  44. stations or an individual station and a multiport controller.
  45.  
  46.         This  protocol allows for the establishment of more  than 
  47. one  link-layer  connection  per  device, if  the  device  is  so 
  48. capable.
  49.  
  50.         This  protocol  does not  prohibit  self-connections.   A 
  51. self-connection  is considered to be when a device establishes  a 
  52. link  to  itself using its own address for both  the  source  and 
  53. destination of the frame.
  54.  
  55.         Most  link-layer  protocols assume that one  primary  (or 
  56. master)  device  (generally  called  a  DCE,  or  data   circuit-
  57. terminating equipment) is connected to one or more secondary  (or 
  58. slave)  device(s)  (usually  called a DTE,  or  data  terminating 
  59. equipment).   This type of unbalanced operation is not  practical 
  60. in a shared-RF Amateur Radio environment.  Instead, AX.25 assumes 
  61. that  both  ends  of  the link are of  the  same  class,  thereby 
  62. eliminating  the two different classes of devices.  The term  DXE 
  63. is  used in this protocol specification to describe the  balanced 
  64.  
  65. 2.2  Frame Structure
  66.  
  67.         Link  layer packet radio transmissions are sent in  small 
  68. blocks of data, called frames.  Each frame is made up of  several 
  69. smaller groups, called fields.  Fig.1 shows the three basic types 
  70. of  frames.  Note that the first bit to be transmitted is on  the 
  71. left side.
  72.  
  73.  
  74.  
  75.         First
  76.         Bit Sent
  77.  
  78.           Flag      Address     Control     FCS      Flag
  79.         01111110  112/560 Bits  8 Bits    16 Bits  01111110
  80.  
  81.                 Fig. 1A -- U and S frame construction
  82.  
  83.  
  84.  
  85.         First
  86.         Bit Sent
  87.  
  88.  Flag      Address      Control    PID    Info.       FCS      Flag
  89.  01111110  112/560 Bits   8 Bits   8 Bits  N*8 Bits   16 Bits  01111110
  90.  
  91.                 Fig. 1B -- Information frame construction
  92.  
  93.  
  94.  
  95.         Each field is made up of an integral number of octets (or 
  96. bytes), and serves a specific function as outlined below.
  97.  
  98. 2.2.1  Flag Field
  99.  
  100.         The flag field is one octet long.  Since the flag is used 
  101. to  delimit  frames, it occurs at both the beginning and  end  of 
  102. each  frame.  Two frames may share one flag, which  would  denote 
  103. the  end of the first frame, and the start of the next frame.   A 
  104. flag consists of a zero followed by six ones followed by  another 
  105. zero,  or  01111110 (7E hex).  As a result of bit  stuffing  (see 
  106. 2.2.6,  below),  this sequence is not allowed to  occur  anywhere 
  107. else inside a complete frame.
  108.  
  109. 2.2.2  Address Field
  110.  
  111.         The address field is used to identify both the source  of 
  112. the  frame and its destination.  In addition, the  address  field 
  113. contains  the  command/response information  and  facilities  for 
  114. level 2 repeater operation.  
  115.  
  116.         The encoding of the address field is described in 2.2.13.
  117.  
  118.  
  119.         The  control field is used to identify the type of  frame 
  120. being  passed  and  control several attributes  of  the  level  2 
  121. connection.   It  is  one octet in length, and  its  encoding  is 
  122. discussed in 2.3.2.1, below.
  123.  
  124. 2.2.4  PID Field
  125.  
  126.         The  Protocol  Identifier  (PID) field  shall  appear  in 
  127. information  frames (I and UI) only.  It identifies what kind  of 
  128. layer 3 protocol, if any, is in use.
  129.  
  130.         The PID itself is not included as part of the octet count 
  131. of the information field.  The encoding of the PID is as follows:
  132.  
  133.  
  134.  
  135.   M      L
  136.   S      S 
  137.   B      B
  138.   yy01yyyy AX.25 layer 3 implemented.
  139.   yy10yyyy AX.25 layer 3 implemented.
  140.   11001100 Internet Protocol datagram layer 3 implemented.
  141.   11001101 Address resolution protocol layer 3 implemented.
  142.   11110000 No layer 3 implemented.
  143.   11111111 Escape character.  Next octet contains more Level 3
  144.            protocol information.
  145.  
  146.  
  147.  
  148.         Where:
  149.  
  150.         A y indicates all combinations used.
  151.  
  152.         Note:
  153.  
  154.         All  forms  of  yy11yyyy and yy00yyyy  other  than  those 
  155. listed  above  are  reserved  at this time  for  future  level  3 
  156. protocols.   The  assignment of these formats is  up  to  amateur 
  157. agreement.   It  is  recommended that the  creators  of  level  3 
  158. protocols   contact  the  ARRL  Ad  Hoc  Committee   on   Digital 
  159. Communications for suggested encodings.
  160.  
  161. 2.2.5  Information Field
  162.  
  163.         The  information field is used to convey user  data  from 
  164. one  end of the link to the other.  I fields are allowed in  only 
  165. three  types of frames:  the I frame, the UI frame, and the  FRMR 
  166. frame.   The  I  field can be up to 256 octets  long,  and  shall 
  167. contain  an integral number of octets.  These  constraints  apply 
  168. prior to the insertion of zero bits as specified in 2.2.6, below.  
  169. Any  information  in the I field shall be passed along  the  link 
  170. transparently,  except  for the zero-bit  insertion  (see  2.2.6) 
  171. necessary  to prevent flags from accidentally appearing in the  I 
  172.  
  173. 2.2.6  Bit Stuffing
  174.  
  175.         In  order to assure that the flag bit sequence  mentioned 
  176. above  doesn't appear accidentally anywhere else in a frame,  the 
  177. sending  station  shall monitor the bit sequence for a  group  of 
  178. five  or more contiguous one bits.  Any time five contiguous  one 
  179. bits  are sent the sending station shall insert a zero bit  after 
  180. the  first  one  bit.   During frame  reception,  any  time  five 
  181. contiguous  one  bits  are  received,  a  zero  bit   immediately 
  182. following five one bits shall be discarded.
  183.  
  184. 2.2.7  Frame-Check Sequence
  185.  
  186.         The  frame-check sequence (FCS) is a  sixteen-bit  number 
  187. calculated  by  both the sender and receiver of a frame.   It  is 
  188. used  to  insure that the frame was not corrupted by  the  medium 
  189. used to get the frame from the sender to the receiver.  It  shall 
  190. be calculated in accordance with ISO 3309 (HDLC) Recommendations.
  191.  
  192. 2.2.8  Order of Bit Transmission
  193.  
  194.         With  the  exception of the FCS field, all fields  of  an 
  195. AX.25 frame shall be sent with each octet's least-significant bit 
  196. first.  The FCS shall be sent most-significant bit first.
  197.  
  198. 2.2.9  Invalid Frames
  199.  
  200.         Any frame consisting of less than 136 bits (including the 
  201. opening  and closing flags), not bounded by opening  and  closing 
  202. flags, or not octet aligned (an integral number of octets), shall 
  203. be  considered  an  invalid frame by the link  layer.   See  also 
  204. 2.4.4.4, below.
  205.  
  206. 2.2.10  Frame Abort
  207.  
  208.         If a frame must be prematurely aborted, at least  fifteen 
  209. contiguous ones shall be sent with no bit stuffing added.
  210.  
  211. 2.2.11  Interframe Time Fill
  212.  
  213.         Whenever   it  is  necessary  for  a  DXE  to  keep   its 
  214. transmitter  on  while  not actually  sending  frames,  the  time 
  215. between frames should be filled with contiguous flags.
  216.  
  217. 2.2.12  Link Channel States
  218.  
  219.         Not applicable.
  220.  
  221. 2.2.13  Address-Field Encoding
  222.  
  223.         The  address  field of all frames shall be  encoded  with 
  224. both the destination and source amateur call signs for the frame.  
  225. Except  for the Secondary Station Identifier (SSID), the  address 
  226. characters only.  If level 2 amateur "repeaters" are to be  used, 
  227. their call signs shall also be in the address field.
  228.  
  229.         The  HDLC address field is extended beyond one  octet  by 
  230. assigning  the  least-significant  bit of each  octet  to  be  an 
  231. "extension bit".  The extension bit of each octet is set to zero, 
  232. to indicate the next octet contains more address information,  or 
  233. one,  to  indicate  this is the last octet of  the  HDLC  address 
  234. field.   To make room for this extension bit, the  amateur  Radio 
  235. call sign information is shifted one bit left.
  236.  
  237. 2.2.13.1  Nonrepeater Address-Field Encoding
  238.  
  239.         If  level  2 repeaters are not being  used,  the  address 
  240. field is encoded as shown in Fig. 2.  The destination address  is 
  241. the call sign and SSID of the amateur radio station to which  the 
  242. frame is addressed, while the source address contains the amateur 
  243. call  sign  and SSID of the station that sent the  frame.   These 
  244. call signs are the call signs of the two ends of a level 2  AX.25 
  245. link only.
  246.  
  247.  
  248.  
  249.         First
  250.         Octet Sent
  251.  
  252.                      Address Field of Frame
  253.         Destination Address         Source Address
  254.         A1 A2 A3 A4 A5 A6 A7    A8 A9 A10 A11 A12 A13 A14
  255.  
  256.         Fig. 2 -- Nonrepeater Address-Field Encoding
  257.  
  258.  
  259.  
  260.         A1  through A14 are the fourteen octets that make up  the 
  261. two  address  subfields of the address  field.   The  destination 
  262. subaddress is seven octets long (A1 thru A7), and is sent  first.  
  263. This  address sequence provides the receivers of frames  time  to 
  264. check  the  destination address subfield to see if the  frame  is 
  265. addressed to them while the rest of the frame is being  received.  
  266. The  source  address subfield is then sent in octets  A8  through 
  267. A14.   Both  of these subfields are encoded in the  same  manner, 
  268. except  that  the last octet of the address field  has  the  HDLC 
  269. address extension bit set.
  270.  
  271.         There  is  an octet at the end of each  address  subfield 
  272. that contains the Secondary Station Identifier (SSID).  The  SSID 
  273. subfield  allows an Amateur Radio operator to have more than  one 
  274. packet-radio station operating under the same call sign.  This is 
  275. useful when an amateur wants to put up a repeater in addition  to 
  276. a regular station, for example.  The C bits (see 2.4.1.2,  below) 
  277. and H bit (see 2.2.13.2, below) are also contained in this octet, 
  278. along with two bits which are reserved for future use.
  279.  
  280. mode of operation.
  281.  
  282.  
  283.  
  284.         Octet   ASCII   Bin.Data  Hex Data
  285.  
  286.         Flag            01111110     7E
  287.          A1       K     10010110     96
  288.          A2       8     01110000     70
  289.          A3       M     10011010     9A
  290.          A4       M     10011010     9A
  291.          A5       O     10011110     9E
  292.          A6     space   01000000     40
  293.          A7     SSID    11100000     E0
  294.          A8       W     10101110     AE
  295.          A9       B     10000100     84
  296.          A10      4     01100100     68
  297.          A11      J     10010100     94
  298.          A12      F     10001100     8C
  299.          A13      I     10010010     92
  300.          A14    SSID    01100001     61
  301.        Control    I     00111110     3E
  302.          PID    none    11110000     F0
  303.          FCS    part 1  XXXXXXXX     HH
  304.          FCS    part 2  XXXXXXXX     HH
  305.         Flag            01111110     7E
  306.  
  307.         Bit position    76543210
  308.  
  309.       Fig. 3A -- Nonrepeater AX.25 frame
  310.  
  311.  
  312.  
  313.         The frame shown is an I frame, not going through a  level 
  314. 2 repeater, from WB4JFI (SSID=0) to K8MMO (SSID=0), with no level 
  315. 3  protocol.   The P/F bit is set; the  receive  sequence  number 
  316. (N(R)) is 1; the send sequence number (N(S)) is 7.
  317.  
  318. 2.2.13.1.1  Destination Subfield Encoding
  319.  
  320.         Fig.  3 shows how an amateur call sign is placed  in  the 
  321. destination address subfield, occupying octets A1 thru A7.
  322.  
  323.  
  324.  
  325.              Octet   ASCII   Bin.Data   Hex Data
  326.  
  327.               A1       W     10101110      AE
  328.               A2       B     10000100      84
  329.               A3       4     01101000      68
  330.               A4       J     10010100      94
  331.               A5       F     10001100      8C
  332.               A6       I     10010010      92
  333.               A7     SSID    CRRSSID0
  334.            Bit Position-->   76543210
  335.  
  336.           Fig. 3 -- Destination Field Encoding
  337.  
  338.  
  339.  
  340.         Where:
  341.  
  342.         1.  The top octet (A1) is the first octet sent, with  bit 
  343.             0  of each octet being the first bit sent, and bit  7 
  344.             being the last bit sent.
  345.  
  346.         2.  The  first (low-order or bit 0) bit of each octet  is 
  347.             the HDLC address extension bit, which is set to  zero 
  348.             on all but the last octet in the address field, where 
  349.             it is set to one.
  350.  
  351.        3.   The  bits marked "r" are reserved bits.  They may  be 
  352.             used in an agreed-upon manner in individual networks.  
  353.             When not implemented, they should be set to one.
  354.  
  355.         4.  The  bit marked "C" is used as  the  command/response 
  356.             bit of an AX.25 frame, as outlined in 2.4.1.2 below.
  357.  
  358.         5.  The  characters of the call sign should  be  standard 
  359.             seven-bit  ASCII  (upper  case only)  placed  in  the 
  360.             leftmost seven bits of the octet to make room for the 
  361.             address  extension  bit.  If the call  sign  contains 
  362.             fewer  than six characters, it should be padded  with 
  363.             ASCII spaces between the last call sign character and 
  364.             the SSID octet.
  365.  
  366.         6.  The  0000  SSID is reserved for  the  first  personal 
  367.             AX.25 station. This establishes one standard SSID for 
  368.             "normal" stations to use for the first station.
  369.  
  370. 2.2.13.2  Level 2 Repeater-Address Encoding
  371.  
  372.         If  a  frame  is to go through  level  2  amateur  packet 
  373. repeater(s), there is an additional address subfield appended  to 
  374. the end of the address field.  This additional subfield  contains 
  375. the call sign(s) of the repeater(s) to be used.  This allows more 
  376. than one repeater to share the same RF channel.  If this subfield 
  377. exists,  the  last octet of the source subfield has  its  address 
  378. extension  bit  set to zero, indicating that  more  address-field 
  379. data  follows.  The repeater-address subfield is encoded  in  the 
  380. same  manner  as the destination and  source  address  subfields, 
  381. except for the most-significant bit in the last octet, called the 
  382. "H" bit.  The H bit is used to indicate whether a frame has  been 
  383. repeated or not.
  384.  
  385.         In  order  to provide some method of  indicating  when  a 
  386. frame has been repeated, the H bit is set to zero on frames going 
  387. to  a repeater.  The repeater will set the H bit to one when  the 
  388. discard  any frames going to the repeater (uplink frames),  while 
  389. operating  through  a repeater.  Fig. 4 shows how  the  repeater- 
  390. address subfield is encoded.  Fig. 4A is an example of a complete 
  391. frame after being repeated.
  392.  
  393.  
  394.  
  395.                 Octet   ASCII   Bin.Data  Hex Data
  396.  
  397.                  A15      W     10101110     AE
  398.                  A16      B     10000100     84
  399.                  A17      4     01101000     68
  400.                  A18      J     10010100     94
  401.                  A19      F     10001100     8C
  402.                  A20      I     10010010     92
  403.                  A21    SSID    HRRSSID1
  404.  
  405.               Bit Order  -->    76543210
  406.  
  407.               Fig. 4 -- Repeater-address encoding
  408.  
  409.  
  410.  
  411.    Where:
  412.  
  413.    1.  The  top octet is the first octet sent, with bit  0  being 
  414.        sent first and bit 7 sent last of each octet.
  415.  
  416.    2.  As  with  the  source and  destination  address  subfields 
  417.        discussed  above, bit 0 of each octet is the HDLC  address 
  418.        extension  bit, which is set to zero on all but  the  last 
  419.        address octet, where it is set to one.
  420.  
  421.    3.  The  "R"  bits are reserved in the same manner as  in  the 
  422.        source and destination subfields.
  423.  
  424.    4.  The  "H" bit is the has-been-repeated bit.  It is  set  to 
  425.        zero  whenever a frame has not been repeated, and  set  to 
  426.        one by the repeater when the frame has been repeated.
  427.  
  428.  
  429.  
  430.         Octet    ASCII   Bin.Data  Hex Data
  431.  
  432.         Flag             01111110     7E
  433.          A1        K     10010110     96
  434.          A2        8     01110000     70
  435.          A3        M     10011010     9A
  436.          A4        M     10011010     9A
  437.          A5        O     10011110     9E
  438.          A6      space   01000000     40
  439.          A7      SSID    11100000     E0
  440.          A8        W     10101110     AE
  441.          A9        B     10000100     84
  442.          A11       J     10010100     94
  443.          A12       F     10001100     8C
  444.          A13       I     10010010     92
  445.          A14     SSID    01100000     60
  446.          A15       W     10101110     AE
  447.          A16       B     10000100     84
  448.          A17       4     01101000     68
  449.          A18       J     10010100     94
  450.          A19       F     10001100     8C
  451.          A20       I     10010010     92
  452.          A21     SSID    11100011     E3
  453.        Control     I     00111110     3F
  454.          PID     none    11110000     F0
  455.          FCS     part 1  XXXXXXXX     HH
  456.          FCS     part 2  XXXXXXXX     HH
  457.         Flag             01111110     7E
  458.  
  459.         Bit position     76543210
  460.  
  461.       Fig. 4A -- AX.25 frame in repeater mode
  462.  
  463.  
  464.  
  465.         The  above frame is the same as Fig. 3A, except  for  the 
  466. addition of a repeater-address subfield (WB4JFI, SSID=1).  The  H 
  467. bit is set, indicating this is from the output of the repeater.
  468.  
  469. 2.2.13.3 Multiple Repeater Operation
  470.  
  471.         The  link-layer AX.25 protocol allows  operation  through 
  472. more  than  one  repeater, creating  a  primitive  frame  routing 
  473. mechanism.   Up to eight repeaters may be used by  extending  the 
  474. repeater-address subfield.  When there is more than one  repeater 
  475. address,  the repeater address immediately following  the  source 
  476. address  subfield  will be considered the address  of  the  first 
  477. repeater  of  a multiple-repeater chain.  As a  frame  progresses 
  478. through  a chain of repeaters, each successive repeater will  set 
  479. the  H bit (has-been-repeated bit) in its SSID octet,  indicating 
  480. that  the  frame has been successfully repeated through  it.   No 
  481. other  changes  to the frame are made (except for  the  necessary 
  482. recalculation of the FCS).  The destination station can determine 
  483. the  route  the frame took to each it by  examining  the  address 
  484. field.
  485.  
  486.         The  number of repeater addresses is variable.   All  but 
  487. the last repeater address will have the address extension bits of 
  488. all  octets  set to zero, as will all but the  last  octet  (SSID 
  489. octet) of the last repeater address.  The last octet of the  last 
  490. repeater address will have the address extension bit set to  one, 
  491. indicating the end of the address field.
  492.  
  493.         It should be noted that various timers (see 2.4.7, below) 
  494. may  have  to be adjusted to accommodate  the  additional  delays 
  495. encountered  when a frame must pass through  a  multiple-repeater 
  496. same path before reaching the source device.
  497.  
  498.         It  is anticipated that multiple-repeater operation is  a 
  499. temporary method of interconnecting stations over large distances 
  500. until  such  time that a layer 3 protocol is in use.   Once  this 
  501. layer 3 protocol becomes operational, repeater chaining should be 
  502. phased out.
  503.  
  504. 2.3  Elements of Procedure
  505.  
  506. 2.3.1  
  507.      The  elements of procedure are defined in terms  of  actions 
  508. that occur on receipt of frames.
  509.  
  510. 2.3.2  Control-Field Formats and State Variables
  511.  
  512. 2.3.2.1  Control-Field Formats
  513.  
  514.         The control field is responsible for identifying the type 
  515. of  frame  being sent, and is also used to  convey  commands  and 
  516. responses  from  one  end of the link to the other  in  order  to 
  517. maintain proper link control.
  518.  
  519.         The  control  fields  used in AX.25 use  the  CCITT  X.25 
  520. control fields for balanced operation (LAPB), with an  additional 
  521. control field taken from ADCCP to allow connectionless and round-
  522. table operation.
  523.  
  524.         There are three general types of AX.25 frames.  They  are 
  525. the Information frame (I frame), the Supervisory frame (S frame), 
  526. and  the  Unnumbered  frame (U frame).  Fig. 5  shows  the  basic 
  527. format  of  the  control field associated  with  these  types  of 
  528. frames.
  529.  
  530.  
  531.  
  532.               Control-Field      Control-Field Bits
  533.                   Type         7  6  5  4  3  2  1  0
  534.   
  535.                 I Frame          N(R)   P    N(S)   0
  536.                 S Frame          N(R)  P/F S  S  0  1
  537.                 U Frame        M  M  M P/F M  M  1  1
  538.  
  539.                   Fig. 5 -- Control-field formats
  540.  
  541.  
  542.  
  543.         Where:
  544.  
  545.         1.  Bit 0 is the first bit sent and bit 7 is the last bit 
  546.             sent of the control field.
  547.  
  548.         2.  N(S) is the send sequence number (bit 1 is the LSB).
  549.  
  550.             LSB).
  551.  
  552.         4.  The  "S" bits are the supervisory function bits,  and 
  553.             their encoding is discussed in 2.3.4.2.
  554.  
  555.         5.  The  "M" bits are the unnumbered frame modifier  bits 
  556.             and their encoding is discussed in 2.3.4.3.
  557.  
  558.         6.  The  P/F bit is the Poll/Final bit.  Its function  is 
  559.             described in 2.3.3.  The distinction between  command 
  560.             and response, and therefore the distinction between P 
  561.             bit and F bit, is made by addressing rules  discussed 
  562.             in 2.4.1.2.
  563.  
  564. 2.3.2.1.1  Information-Transfer Format
  565.  
  566.         All I frames have bit 0 of the control field set to zero.  
  567. N(S)  is  the sender's send sequence number  (the  send  sequence 
  568. number  of  this frame).  N(R) is the sender's  receive  sequence 
  569. number (the sequence number of the next expected received frame).  
  570. These numbers are described in 2.3.2.4.  In addition, the P/F bit 
  571. is to be used as described in 2.4.2.  
  572.  
  573.  
  574. 2.3.2.1.2  Supervisory Format
  575.  
  576.         Supervisory  frames  are denoted by having bit 0  of  the 
  577. control  field set to one, and bit 1 of the control field set  to 
  578. zero.   S  frames  provide  supervisory  link  control  such   as 
  579. acknowledging or requesting retransmission of I frames, and link-
  580. level window control.  Since S frames do not have an  information 
  581. field,  the  sender's send variable and  the  receiver's  receive 
  582. variable are not incremented for S frames.  In addition, the  P/F 
  583. bit is used as described in 2.4.2.
  584.  
  585. 2.3.2.1.3  Unnumbered Format
  586.  
  587.         Unnumbered frames are distinguished by having both bits 0 
  588. and 1 of the control field set to one.  U frames are  responsible 
  589. for  maintaining additional control over the link beyond what  is 
  590. accomplished  with  S  frames.  They  are  also  responsible  for 
  591. establishing  and  terminating link connections.  U  frames  also 
  592. allow  for the transmission and reception of information  outside 
  593. of   the  normal  flow  control.   Some  U  frames  may   contain 
  594. information and PID fields.  The P/F bit is used as described  in 
  595. 2.4.2.
  596.  
  597. 2.3.2.2  Control-Field Parameters
  598.  
  599. 2.3.2.3  Sequence Numbers
  600.  
  601.         Every  AX.25  I  frame shall be  assigned,  modulo  8,  a 
  602. sequential  number  from  0 to 7.  This will allow  up  to  seven 
  603. outstanding I frames per level 2 connection at a time.
  604. 2.3.2.4  Frame Variables and Sequence Numbers
  605.  
  606. 2.3.2.4.1  Send State Variable V(S)
  607.  
  608.         The send state variable is a variable that is internal to 
  609. the  DXE  and  is never sent.  It contains  the  next  sequential 
  610. number  to  be assigned to the next transmitted  I  frame.   This 
  611. variable is updated upon the transmission of each I frame.
  612.  
  613. 2.3.2.4.2  Send Sequence Number N(S)
  614.  
  615.         The send sequence number is found in the control field of 
  616. all  I  frames.  It contains the sequence number of the  I  frame 
  617. being sent.  Just prior to the transmission of the I frame,  N(S) 
  618. is updated to equal the send state variable.
  619.   
  620.  
  621. 2.3.2.4.3 Receive State Variable V(R)
  622.  
  623.         The receive state variable is a variable that is internal 
  624. to the DXE.  It contains the sequence number of the next expected 
  625. received I frame.  This variable is updated upon the reception of 
  626. an  error-free  I  frame whose send sequence  number  equals  the 
  627. present received state variable value.
  628.  
  629. 2.3.2.4.4  Received Sequence Number N(R)
  630.  
  631.         The  received sequence number is in both I and S  frames.  
  632. Prior  to  sending an I or S frame, this variable is  updated  to 
  633. equal  that  of  the received  state  variable,  thus  implicitly 
  634. acknowledging  the  proper  reception of all  frames  up  to  and 
  635. including N(R)-1.
  636.  
  637. 2.3.3  Functions of Poll/Final (P/F) Bit
  638.  
  639.         The  P/F bit is used in all types of frames.  It is  used 
  640. in  a  command  (poll) mode to request an immediate  reply  to  a 
  641. frame.   The  reply  to this poll is  indicated  by  setting  the 
  642. response  (final)  bit  in  the  appropriate  frame.   Only   one 
  643. outstanding  poll condition per direction is allowed at  a  time.  
  644. The procedure for P/F bit operation is described in 2.4.2.
  645.  
  646. 2.3.4  Control Field Coding for Commands and Responses
  647.  
  648.         The following commands and responses, indicated by  their 
  649. control field encoding, are to be use by the DXE:
  650.  
  651. 2.3.4.1  Information Command Frame Control Field
  652.  
  653.         The  function  of  the  information  (I)  command  is  to 
  654. transfer   across  a  data  link  sequentially  numbered   frames 
  655. containing an information field.
  656.  
  657.         The  information-frame control field is encoded as  shown 
  658. subfield to maintain control of their passage over the link-layer 
  659. connection.
  660.  
  661.  
  662.  
  663.                           Control Field Bits
  664.                            7 6 5 4 3 2 1 0
  665.                             N(R) P  N(S) 0
  666.  
  667.                     Fig. 6 -- I frame control field
  668.  
  669.  
  670.  
  671. 2.3.4.2  Supervisory Frame Control Field
  672.  
  673.         The supervisory frame control fields are encoded as shown 
  674. in Fig. 7.
  675.  
  676.  
  677.  
  678.         Control Field Bits       7   6   5   4   3   2   1   0
  679.         Receive Ready     RR        N(R)    P/F  0   0   0   1
  680.         Receive Not Ready RNR       N(R)    P/F  0   1   0   1
  681.         Reject            REJ       N(R)    P/F  1   0   0   1
  682.  
  683.                 Fig. 7 -- S frame control fields
  684.  
  685.  
  686.                           The Frame identifiers:
  687.  
  688. C or SABM          Layer 2 Connect Request
  689. D or DISC          Layer 2 Disconnect Request
  690. I                  Information Frame
  691. RR                 Receive Ready. System Ready To Receive
  692. RNR or NR          Receive Not Ready. TNC Buffer Full
  693. RJ or REJ          Reject Frame. Out of Sequence or Duplicate
  694. FRMR               Frame Reject. Fatal Error
  695. UI                 Unnumbered Information Frame. "Unproto"
  696. DM                 Disconnect Mode. System Busy or Disconnected.
  697.  
  698.  
  699. 2.3.4.2.1  Receive Ready (RR) Command and Response
  700.  
  701.         Receive Ready is used to do the following:
  702.  
  703.    1.  to  indicate  that the sender of the RR is  now  able  to 
  704.        receive more I frames.
  705.  
  706.    2.  to  acknowledge  properly  received I frames  up  to,  and 
  707.        including N(R)-1, and
  708.  
  709.    3.  to clear a previously set busy condition created by an RNR 
  710.        command having been sent.
  711.  
  712. requested  by  sending a RR command frame with the P-bit  set  to 
  713. one.
  714.  
  715. 2.3.4.2.2  Receive Not Ready (RNR) Command and Response
  716.  
  717.         Receive Not Ready is used to indicate to the sender of  I 
  718. frames  that  the receiving DXE is temporarily  busy  and  cannot 
  719. accept any more I frames.  Frames up to N(R)-1 are  acknowledged.  
  720. Any I frames numbered N(R) and higher that might have been caught 
  721. between states and not acknowledged when the RNR command was sent 
  722. are not acknowledged.
  723.  
  724.         The RNR condition can be cleared by the sending of a  UA, 
  725. RR, REJ, or SABM frame.
  726.  
  727.         The status of the DXE at the other end of the link can be 
  728. requested  by sending a RNR command frame with the P bit  set  to 
  729. one.
  730.  
  731. 2.3.4.2.3  Reject (REJ) Command and Response
  732.  
  733.         The  reject frame is used to request retransmission of  I 
  734. frames  starting  with N(R).  Any frames that were  sent  with  a 
  735. sequence number of N(R)-1 or less are acknowledged.  Additional I 
  736. frames may be appended to the retransmission of the N(R) frame if 
  737. there are any.
  738.  
  739.         Only  one  reject  frame condition  is  allowed  in  each 
  740. direction  at  a time.  The reject condition is  cleared  by  the 
  741. proper  reception of I frames up to the I frame that  caused  the 
  742. reject condition to be initiated.
  743.  
  744.         The status of the DXE at the other end of the link can be 
  745. requested  by sending a REJ command frame with the P bit  set  to 
  746. one.
  747.  
  748. 2.3.4.3  Unnumbered Frame Control Fields
  749.  
  750.         Unnumbered  frame control fields are either  commands  or 
  751. responses.
  752.  
  753.         Fig.  8 shows the layout of U frames  implemented  within 
  754. this protocol.
  755.  
  756.  
  757.  
  758.         Control Field                Type     Control Field Bits
  759.                                             7  6  5  4  3  2  1  0
  760.  
  761. Set Asynchronous Balanced Mode-SABM  Cmd    0  0  1  P  1  1  1  1
  762. Disconnect-DISC                      Cmd    0  1  0  P  0  0  1  1
  763. Disconnected Mode-DM                 Res    0  0  0  F  1  1  1  1
  764. Unnumbered Acknowledge-UA            Res    0  1  1  F  0  0  1  1
  765. Frame Reject-FRMR                    Res    1  0  0  F  0  1  1  1
  766.  
  767.                 Fig. 8 -- U frame control fields
  768.  
  769.  
  770.  
  771. 2.3.4.3.1  Set Asynchronous Balanced Mode (SABM) Command
  772.  
  773.         The  SABM  command  is  used  to  place  2  DXEs  in  the 
  774. asynchronous balanced mode.  This is a balanced mode of operation 
  775. known as LAPB where both devices are treated as equals.
  776.  
  777.         Information fields are not allowed in SABM commands.  Any 
  778. outstanding  I frames left when the SABM command is  issued  will 
  779. remain unacknowledged.
  780.  
  781.         The  DXE  confirms  reception and acceptance  of  a  SABM 
  782. command   by  sending  a  UA  response  frame  at  the   earliest 
  783. opportunity.   If  the  DXE is not capable of  accepting  a  SABM 
  784. command, it should respond with a DM frame if possible.
  785.  
  786. 2.3.4.3.2  Disconnect (DISC) Command
  787.  
  788.         The  DISC  command is used to terminate  a  link  session 
  789. between  two  stations.  No information field is permitted  in  a 
  790. DISC command frame.
  791.  
  792.         Prior  to  acting on the DISC frame,  the  receiving  DXE 
  793. confirms acceptance of the DISC by issuing a UA response frame at 
  794. its  earliest opportunity.  The DXE sending the DISC  enters  the 
  795. disconnected state when it receives the UA response.
  796.  
  797.         Any  unacknowledged  I frames left when this  command  is 
  798. acted upon will remain unacknowledged.
  799.  
  800.  
  801.